December 26, 1995 (hereinafter "Matoba") in view of Miller, U.S. patent number 
6,101,481 issued on August 8, 2000 (hereinafter "Miller"). Together, Matoba and Miller 
will be referred to as the "combined references." 

Applicant respectfully does not believe that the Patent Office has met its burden 
of making a prima facie case of obviousness. As described in numerous places in the 
MPEP: 

To establish a prima facie case of obviousness, three basic criteria 
must be met. First, there must be some suggestion or motivation either in 
the references themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to combine reference 
teaching. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach 
or suggest all the claim limitations. The teaching or suggestion to make 
the claimed combination and the reasonable expectation of success must 
both be found in the prior art, and not based on the applicant's disclosure. 
[Citations omitted]. MPEP §2142 (May 2004). 

In particular, the Patent Office has not adequately identified the teaching or 
suggestion in either Matoba or Miller to combine their subject matter in such a way as to 
describe the Applicant's invention. Since the motivation to combine the references is not 
immediately apparent to the Applicant, who believes that the subject matter of both 
references is considerably different from the present invention, it is the "duty of the 
examiner to explain why the combination of the teaching is proper." MPEP §2142 (May 
2004). The Office Action's description of the motivation to combine Matoba with Miller 
is limited to the statement that "Miller's method of updating information related each 
component [sic] and notifying the other component would improve Matoba system by 
allowing each component to know the status and other information about the other 
component." Office Action, Tf5. This statement is made without the required "reasonable 
specificity" to the cited references required to establish a prima facie case. Further, an 
unsupported conclusion that something would "improve" something else without specific 
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citation to a teaching or suggestion in the prior art - particularly when asserted to track 
the Applicant's invention — implies that the description of the improvement is improperly 
drawn from the applicant's disclosure, rather than from any teaching or suggestion found 
in the prior art. See, MPEP §2142 (May 2004). 

With regard to the present invention, the requirement "that the prior art reference 
(or references when combined) must teach or suggest all the claim limitations" to 
establish a prima facie case is clearly not met in the Office Action. The assertion of 
Matoba in the first Office Action as anticipating each an every element of the present 
claims has been withdrawn in favor of the combination between Matoba and Miller under 
§ 103(a). The following comments will demonstrate that Matoba remains a deficient 
reference even in combination with Miller in that they do not teach each an every element 
of the rejected claims. Before addressing the claims in detail, a brief, high-level, 
description contrasting Matoba, Miller and the present invention is provided. 

A Brief Review Of Matoba. 

Matoba teaches a fairly complex production planning system that, with the 
assistance of considerable human operator intervention, helps plan the production of 
unspecified items. Applicant is unable to find any indication that the system actually 
produces anything, but is rather a sophisticated scheduling guide that employs many 
specialized devices to adjust a proposed schedule based on the analysis of a number of 
external factors such as shop availability, empirically determined "lateness" of various 
production steps, prequalification of the production steps, interactive adjustments made 
by a user using the system, etc. These devices feed their conclusions to a central "MRP 
Calculation Control Device," which adjusts the centralized, proposed schedule 
accordingly. There are numerous graphical displays that employ conventional workflow 
diagrams that show contiguous blocks, each representing a block of time used for that 
production step. 
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At its core, Matoba teaches a sophisticated production scheduling aid that requires 
considerably human interaction to operate. It displays information using conventional 
workflow-type diagrams and provides conventional interface controls that allow for the 
human operator to input/adjust the values. The calculation of the effect of adjustment 
values is the most the complicated area of the Matoba invention. In particular, Matoba 
employs techniques to integrate several production steps and production chains (e.g., 
shops) into a single production timeline. 

Undoubtedly, the system described in Matoba took many hundreds of person 
hours to construct using entirely conventional programming techniques. The Matoba 
program is dedicated to a specific use. While providing many tools to assist a human 
operator with production scheduling, its disclosure suggests no adaptability to other uses 
beyond production scheduling nor does it suggest extensibility beyond what it is 
specifically programmed to do. 

A Brief Review Of Miller. 

Miller also describes a program for "managing a plurality of tasks to be carried 
out by a plurality of personnel." Miller, col. 1, lines 6-7. The tasks are defined by a user 
through a conventional input form shown in Figure 2. These "overall tasks" are "then 
broken into smaller tasks (parts) which describe how the task will be done." Miller, col. 
6, lines 63-64. Tasks and their sub-tasks can be displayed through conventional GANTT 
or bar charts (Figure 1 A). Like the GANTT and bar charts, the relationship between the 
defined tasks can also be shown in tree form (Figure 1). The display of the tasks can be 
filtered so that only tasks relevant to the viewing person are displayed in any of these 
formats. In essence, Miller displays a schedule to the appropriate human personnel 
responsible for performing a task and restricts changing the schedule to those with 
granted rights to the task. 
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Tasks (and their "smaller tasks") are assigned to human task controllers who are 
the "one person [that] is responsible for each task and only the person responsible [for the 
task] can change task detail for the task." Miller col. 8, lines 18-20. Other persons can 
be assigned the responsibility for performing the tasks or smaller tasks. The security 
issue of having control of a task in other than the person responsible is noted by Miller 
and referenced by the Office Action at col. 1, lines 47-52. Miller's solution of assigning 
the tasks to individual human "task personnel and controllers" is also referenced by the 
Office Action at col. 2, lines 5-9. Applicant respectfully does not understand the 
pertinence of these citations to the pending claims. With reference to the citation by the 
Office Action of col. 2, lines 58-61, Applicant takes the "updating progress of the parent 
task when progress of a child task of the parent has changed" to mean that the Complete 
field associated with the child task is updated to reflect the status of the parent. 

A Brief Review Of The Present Invention. 

It appears possible for the present invention to program all or part of the 
functionality found in the Matoba and Miller systems. However, the converse is not true. 
Neither Matoba or Miller, separately or in combination, describe the present invention's 
methods and systems for programming and executing groupings of time sequenced tasks 
in almost unlimited permutations for almost unlimited applications. In other words, you 
can use a hammer to build a house, but you can't use a house to build a hammer. While 
the systems and methods described in the pending claims provide tools to build 
applications like those described in Matoba and Miller, they go far beyond in their ability 
to enable a relatively unskilled user to develop and use exceptionally complex computer 
programs. As claimed, the present invention does use components that interact with each 
other and can access each other's properties and methods. How these components 
interact with each other and what is accomplished as a result are both patentable subject 
matter that is not found in the cited prior art. 
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In the interest of brevity, Applicant suggests that the Examiner again review 
Amendment B of this application, where a brief example using the invention is described 
starting at page 6. Of particular note in this example is how the components interact with 
each other to form the methods and systems of the present invention. One way to look at 
various aspects of the invention is as a programming tool that provides an easy to 
understand interface for non-programmers to program and/or use complex, executable 
computer programs. 

CLAIMS ARE DISTINCT 

Independent Claim 2 

Claim 2 recites two components that interact in a manner not taught or suggested 
in the combined references. To paraphrase the claim, there is a first component (the 
action date) that has an associated date property and a second component (the action) that 
has an associated executable task method. The combined references do not teach or 
suggest "means for executing the task method" of the action component "based on the 
point in time specified in the date property" of the action date component. As provided 
by the present invention, associating a task method with one component, while 
associating a date property with another component enables a method of the present 
invention to programmatically execute the method of one object at a time associated with 
the another object by simply associating the two objects. This novel and powerful 
functionality is not taught or described by the combined references. The ease with which 
this association is made to form and use powerful, extensible automated task lists is 
recited in the remaining claims. 

The Office Action cites Matoba col. 20 lines 55-65 as teaching elements of this 
claim. Applicant understands this portion of the specification that a DELIVERY DATE 
or a COMPLETION can be altered by master computer program. The altering of 
delivery and completion dates by a master computer program is well known. The 
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problem is that the prior art methods for doing so rely on master programs running 
complex predefined algorithms. Matoba evidences the complexity of the prior art for in 
its 63 columns of description of inputs and algorithms for scheduling dates. The present 
invention, however, does much more than manipulate date fields. 

Miller does nothing to supplement the deficiency of Matoba in describing the 
present invention. While the Applicant maintains the traverse made above that the Office 
Action fails to meet its obligation to sufficiently describe the combination of Matoba and 
Miller to make a prima facie case of obviousness, for the sake of argument we will 
assume that it is known in the prior art to allow "each component to know the status and 
other information about the other component." Office Action, §5. That simple 
assumption, however, does not preempt any future invention that describes novel 
methods and systems that make use of information shared by components. The type and 
location of information and how that information is used by methods of the claimed 
invention define the real questions of patentability in the computer arts. As recited in the 
claims, the methods and systems of the present invention that make use of this 
information are not the subject of any teaching or suggestion in either of the combined 
references. Since all claim elements must be taught or suggested by the combined 
references, the rejection of Claim 2 is improper and the claim should be passed to issue. 

While the claims depending from Independent Claim 2 are further distinguished 
from the combined references below, it should be noted that "[i]f an independent claim is 
nonobvious under 35 U.S.C. 103, then any claim depending therefrom is nonobvious." 
t MPEP §2 1 43 .03 (May 2004). 

Dependant Claim 3 

Claim 3 further recites "means for setting the point in time specified in the date 
property of the child action date component by offsetting from the point in time specified 
in the date property of the parent action date component by an offset value associated 
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with the child action date component." Neither Motoba nor Miller teach or suggest 
setting the date property associated with the child component in the manner recited. For 
example, according to the invention, the date property associated with the child object is 
set a follows: 

Present Invention Example: 




Parent 
Child 



Date Property 
Offset Value 



May 10, 2005 
30 days 1 

111 



The Office Action cites Matoba col. 16 lines 55-66 and col. 7 lines 38-55. Both 
of these citations discuss a "MRP calculation control device." The implementation of 
this device is the subject of much of the 63 columns of disclosure, which boils down to 
many inputs from many sources input into many algorithms - non of which teach or 
suggest the simple setting means recited in Claim 3. In particular, the date property 
associated with a child action date component is not set by offsetting the date property of 
a parent date component by an offset value associated with the child component. The 
citations to Miller in the Office Action are discussed above at page 4 and are not believed 
by Applicant to be relevant. 



Dependent Claim 4 

Claim 4 recites an action list component that finds find no corresponding structure 
in Matoba or Miller. As with the other component types, Matoba also does not teach 



1 Note that this could be any unit of time, e.g., 10 minutes instead of 10 days offset from 1 :59 PM 
on May 1,2005 
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associating an instance of an action list component with an instance of an action date 
component, nor does Matoba recite the pass through association of the action component 
with the action date component via the action list component. The Office Action cites 
Matoba col. 17 lines 27-56. This portion of Matoba teaches retrieving "a table 43 of 
order numbers with lateness for starting" in response to a human operator selecting an 
"Orders list menu 44." This table 43 appears to be a conventional data table returned 
from the date retention device and does not teach or suggest an action list component that 
provides the recited associations between components. 

In addition to the absence of the description of an action list component, the 
combined reference do not teach or suggest "means for executing the task method 
associated with the instance of the action component based on the point in time specified 
in the date property of the instance of the action date with which the instance of the 
action list component is associated." For example, assume an action list component with 
an associated action component. Further assume that the action component has a task 
method that prints a form document. If the action list component is associated with a 
parent action date component that has an associated date property of May 1, 2005, 
according to the claim recitation, the form document would be printed on May 1, 2005. 
Now assume that the action list component is instead moved (newly associated with) 
another action date component that has an associated date property of May 30, 2005, the 
form document would be printed on May 30, 2005. There is nothing in Motoba or Miller 
that teaches or suggests this type of structure or functionality and Claim 4 should be 
passed to issue. 

Dependent Claim 5 

Claim 5 further recites multiple instances of the same type of component, namely 
a "parent action date component" and a "child action date component". Matoba does not 
describe multiple action date components, nor does it teach the recited association of a 
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child action date component with an instance of the action list component. Further, 
Matoba does not teach setting the date property of the child action date using the offset 
value associated with that child action date and the date property of the parent action date 
component based upon the association of the components. Here is one of many examples 
to read the claim on to: 

Present Invention Example: 




* ... v. 1 s , . I i * , , ,. A^§4|> 




Parent Action Date 
Action List 1 

Child Action Date 
Child Action Date 



Date Property 
Parent 

Parent 
Offset Value 



May 1,2005 
Parent Action 
Date 

Action List 1 
30 days 



(i) 




The Office Action cites Matoba, col. 35 lines 4-49, which partially describes the 
complex algorithm for starting and process completion dates of its invention. This 
algorithm includes finding the order of jobs, idle times, alternative shops, computing load 
and capacity accumulation graphs (regressions?), etc. The other citations are similarly 
extensions of Motoba's extensive algorithm. What isn't described in the combined 
references is the present invention's mean of simply adding (or subtracting, when 
appropriate) the offset value associated with a child action date to the date property 
associated with a parent action date. 

Dependent Claim 6 

Claim 6 further recites multiple instances of action list components, namely 
associating an instance of the action list component with another instance of the action 
list component. Matoba does not describe multiple action list components, nor does it 
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teach the recited association of an action list component with another instance of an 
action list component. 

Dependent Claim 7 

Claim 7 recites associating multiple action list components with a parent 
component grouped by context. The combined references do not describe multiple action 
list components, nor do they teach the recited grouping of action list components by 
context. Further, Claim 7 recites executing the action list component based on an 
occurrence of the associated context. The combined references do not describe executing 
an action list component, nor do they describe executing an action list component based 
on the occurrence of the context it is associated with. 
Independent Claim 8 

The Office Action has rejected Independent Claim 8 based on the same rejection 
as independent Claim 2. Without guidance to the specific language of this claim that 
concerns the Examiner, Applicant directs the Examiner to the comments regarding 
Independent Claim 2 set forth above. However, Applicant would like to underscore that 
the combined references teach only a standalone programs and do not teach or suggest 
the recited object model to use in the programming of automated task lists comprising (1 ) 
an action date object having a date property that specifies a point in time and (2) an 
action object having an associated task method. There is no discussion in the combined 
references of associating or configuring action date and action objects and there is no 
provision made for storing associated instances of the objects as an automated task list. 

Since independent claim 8 is allowable, all of its dependant claims should also be 
allowed. MPEP §2143.03 (May 2004). However, each of the following claims is 
allowable in their own right as they introduce further novel aspects of the invention not 
taught or suggested by the combined references. 
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Dependent Claim 9 

Claim 9 recites a graphical user interface with graphic representations that allow a 
user to generate multiple instances of the action date object and action object, as required 
for the programming of an automated task list. The combined references do not teach 
instancing action date objects or action objects based on the selection of a graphic 
representation of that object, nor do they teach assembling a graphical bolt representation 
of the automated task list using graphic representations of the instanced objects. Figure 2 
of the present application illustrates example graphic representations of the action date 
object (218) and the action object (222-238). Examples of graphic representations of 
instances of these objects are illustrated as 214c, 246f, 214a, etc. Instancing the action 
date object 214c from the graphic representation of the action date object 214 might 
occur, for example, from a drag drop operation from the store window 208 to the bolt 
window 210. The Examiner is directed to the specification for the extended description 
of this process. 

Applicant is unable to find anything in the combined references that teaches or 
suggests the usage of graphic representation of an action date, a graphic representation of 
an action object or the use of the graphic representation in a graphical interface of these 
object instances to assembly into automated task lists. In particular, Applicant would like 
to point out to the Examiner that a reference in Matoba to an "object" is better understood 
as meaning a "target" of an action or a purpose of the invention. "Object" is not used in 
Matoba as an "object" part of an object oriented programming system was would be as 
understood by one of ordinary skill in the computer programming arts. See, e.g., Matoba, 
col. 18 lines 30-50. 

Dependent Claim 10 

Claim 10 recites displaying the Bolt in an alternative format as a checklist. An 
example of one form of a checklist format is shown in Figure 8A-C and is described in 
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the specification. Neither a Bolt nor its display is described or illustrated in the combined 
references. 

Dependent Claim 11 

Claim 1 1 recites an action list object that finds find no corresponding structure in 
the combined references. As with the other object types, the combined references also do 
not teach associating an instance of an action list object with an instance of an action date 
object, nor does Matoba recite the pass-through association of the action object with the 
action date object via the action list object. 

Dependent Claim 12 

Claim 12 recites a graphical user interface having graphic representations that 
allow a user to generate multiple instances of the action date object, action list object and 
action object as required for the programming of an automated task list. The combined 
reference do not teach generating action date objects, action list objects or action objects 
based on the selection of a graphic representation of the object, nor does it teach 
assembling a graphical bolt representation of the automated task list using graphic 
representations of the generated objects. 

Dependent Claim 13 

Claim 13 recites displaying the Bolt in an alternative format as a checklist. An 
example of one form of a checklist format is shown in Figure 8A-C and is described in 
the specification. Neither a bolt nor its display is described in the combined references. 

Dependent Claim 14 

Claim 14 recites associating the graphic representation of the instance of the 
action list object with a context by attaching the instance of the action list object with the 
region associated with the context by way of the graphical user interface. Examples of 
various contexts are illustrated in Figure 1 2 A of the present application and the 
specification. For example, there can be an Auto context(1214), True context (1216), 
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False context (1220), or custom contexts (1224). The combined references do not 
describe the action list objects, let alone associating those object by way of the graphical 
user interface. The combined references also do not teach or describe "associating the 
graphic representation of the instance of the action list object with a context by attaching 
the instance of the action list object with the region associated with the context by way of 
the graphical user interface." 
Dependent Claim 15 

Claim 15 recites storing the constituent automated task list and associating that 
constituent automated task list with a parent task list. The combined references describe 
nothing like an automated task list nor the reuse of automated task lists as constituent 
automated task lists. According to the present invention, any number of constituent 
automated tasks list can be combined to form a master parent automated task list. One 
way to think about this is to imagine a computer program created adding together a 
plurality of smaller computer programs by simple attachment to an action date object. 
The full scope of this very powerful aspect of the present invention can be found in the 
specification. The portions of Matoba cited in the Office Action describes conventional 
displays of information, not automated task list assembly techniques. 

Dependent Claim 16 

Claim 16 recites a graphical user interface with graphic representations that allow 
a user to generate multiple instances of the constituent bolt as required for the 
programming of a parent automated task list. Further, Claim 16 recites using those 
graphic representations to program the parent automated task list by specifying 
associations through the graphical user interface. The combined references do not teach 
instancing a constituent bolt based on the selection of a graphic representation of the 
constituent bolt, nor does it teach assembling a parent bolt using the graphic user 
interface to associate graphic representations of the parent and constituent bolts. 
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Independent Claim 17 

As discussed above, the combined references do not teach an automated task list 
and therefore could not teach executing an automated task list as recited in independent 
claim 17. The combined references also do not teach providing the components, setting 
the date properties associated with the action date components or executing pre- 
configured tasks associated with the action components, all as recited in claim 17. Please 
see the discussion of the cited portions of Miller, above. 

Since independent claim 17 is allowable, all of its dependant claims should also 
be allowed. MPEP §2143.03 (May 2004). 

Dependent Claim 18 

The combined references do not teach or suggest an action list component, an 
action date component and an action list component. They do not teach the association of 
these components and they do not teach the execution of task methods associated with 
these components. All of these elements are recited in Claim 1 8 and none of them find 
corresponding description in the combined references. 

Dependent Claim 19 

The combined references do not teach or suggest an action date component or an 
action list component. Further, it does not teach selectively executing an associated 
action list component based on an analysis of pre-configured conditions. An example of 
the present invention analyzing pre-configured conditions can be found in Figure 14 and 
the specification. There is no corresponding teaching ocsuggestion in the combined 
references for the claimed condition analysis. 

Dependent Claim 20 

Claim 20 recites displaying an automated task list as a graphical bolt in the 
graphical user interface. An example of the Bolt format can be seen in Figure 3 1 or the 
present application. Neither an automated task list nor its display in Bolt format is 
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described in Matoba. Applicant notes that Miller uses a tree as one version of its display. 
However, the task descriptions displayed in that tree are not the objects claimed by the 
present invention (e.g., action date, action list, action etc.) 
Dependent Claim 21 

Claim 21 recites displaying the automated task list in an alternative format as a 
checklist. An example of one form of a checklist format is shown in Figure 8A-C and is 
described in the specification. Neither the automated task list nor its display is described 
in the combined references. 



As described above, the Office Action fails to make a prima facie case that the 
present invention is unpatentable over Matoba in view of Miller. These combined 
references do not teach or suggest each and every element of the claimed invention in any 
substantive way. As such, all of Claims 2-21 are allowable and Applicant respectfully 
requests that this application be passed to issue. The Examiner is invited to call the 
undersigned if he would like to discuss the Application in general or this Response C in 
particular. 



CONCLUSION 



// 



// 
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